貝老闆：小可，我昨天夢到一件事，我們系統要標榜「全年 365 天 24 小時，100% 可用！」這樣客戶才敢來啊！

小可（翻白眼）：老闆，你連電力公司都不敢保證 100%，我們要怎麼保證？

貝老闆：那就寫 SLA 100 啊，不然我們怎麼跟標案拚？

工程師 King（小聲、眼神閃爍）：老闆，如果你真的寫 100%，我們以後誰還敢 deploy 啊……

AI 實習生（單眼怪舉手興奮）：好！我可以幫忙生成「SLA 100% 條款」！

小可（拍額頭）：……你不要再亂答應了啦！這我真的沒辦法解釋，還是打給好威吧。

（電話接通）

好威：蛤？100%？貝哥哥 ~~ 你是要跟上帝簽 SLA 嗎？

貝老闆：客戶就想要 100%，不然不安心嘛！

好威：我幫你拆解一下。工程界通常不談 SLA 100%，因為那意味著「永遠不會壞」，現實上不可能。大家談的是 SLO（Service Level Objective）跟 SLI（Service Level Indicator），再加上 Error Budget 政策。

小可：Error Budget？

好威：對啊，就是把「能允許壞掉的時間」算出來，當作創新的空間。比如說 99.9% 可用性，代表一年可以 downtime 8 小時 45 分鐘。這些時間就是 error budget。如果 bug 太多用光了，那就暫停上線新功能，全力修穩定性。

貝老闆：哦～所以不是寫死 100%，而是要有彈性？

好威：對，你要在「創新速度」和「穩定性」之間找平衡。要是你真的硬寫 100%，工程團隊只敢躺平、不敢動，因為隨便上線就可能違約。最後變成「完全穩定，但完全沒新功能」。

小可（點頭）：這就像信用卡額度，花超過要停卡；Error Budget 用完，就先別推新功能。這樣也比較好跟客戶解釋。

貝老闆：啊啊，原來如此！那我改 slogan：「我們有最嚴謹的 Error Budget 管理！」這樣聽起來是不是很專業？

好威（翻白眼）：至少比「100% 可用」真實多了。

概念拆解

1. SLI（Service Level Indicator）
SLI 是可觀測的指標，像是「可用率」、「反應時間」、「錯誤率」。它是量測的基礎。例如：系統的 API 一天 100 萬次請求中，有 999,800 次成功，那可用率就是 99.98%。

2. SLO（Service Level Objective）
SLO 是對這些指標設定的目標，例如「API 可用率要達到 99.9%」。這是一個承諾，但不是保證，因為它允許在現實中有點瑕疵。

3. SLA（Service Level Agreement）
SLA 則是跟客戶簽訂的合約，通常基於 SLO，但會附帶罰則或補償措施。所以如果 SLA 寫 100%，那代表一旦系統掛掉，就可能賠到哭。

4. Error Budget（錯誤預算）
Error Budget 就是「SLO 允許的誤差」。比如 SLO = 99.9%，那代表每個月最多 downtime 43 分鐘。Error Budget 可以讓團隊在「上線新功能」和「維護穩定性」之間有清楚規則。用完就停推新功能，專心救火。

Takeaways

1. 不要亂喊 100%：工程上沒有絕對穩定，連 Google Cloud 都只敢保證 99.95%。喊 100% 只會讓團隊綁手綁腳，無法創新。

2. 要談 SLO/SLA，而不是空口號：對內要設定 SLO（工程團隊的目標），對外才是 SLA（合約承諾）。SLA 通常會比 SLO 略低，以免過度承諾。

3. Error Budget 是創新的保險機制：有了 Error Budget，團隊知道「還能冒險多少」。這也是跟 AI 協作時要特別說清楚的地方：如果沒給 AI 明確的 SLO，它只會幫你生成一堆程式碼，卻不會幫你思考「系統能承受多少風險」。

4. 如何問 AI？ 如果不懂技術，可以這樣問 AI：「我想要定義我們系統的可靠性，請幫我解釋 SLA、SLO、SLI 和 Error Budget 的差別，並算出 99.9% 可用性代表多久 downtime。」這樣 AI 就能幫你算清楚，還能給實際例子。

今日提問

你覺得你們團隊的 Error Budget 應該設定多少？如果用光了，你會選擇「暫停新功能」還是「硬著頭皮繼續衝」？